Date: Sat, 9 Jan 93 04:30:04 PST 

From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu> 
Errors-To: Packet-Radio-Errors@UCSD.Edu 

Reply-To: Packet-Radio@UCSD.Edu 

Precedence: Bulk 

Subject: Packet-Radio Digest V93 49 

To: packet-radio 


Packet-Radio Digest Sat, 9 Jan 93 Volume 93 : Issue 9 


Today's Topics: 
Ethernet access to JNOS ??°? 
FBB 5.14D Garbled Bulletins 
FEC 
Forwarded msg re: FBB and AA4RE issue. 
G3RUH DSP question (technical) 
Headers..... 
Interfacing packet repeater and TNC 
NOS and POP 
Packet Radio through Internet? 
SLIP on SUNs 


Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu> 
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 6 Jan 93 18:07:13 GMT 

From: deccrl!news.crl.dec.com!dbased.nuo.dec.com!nntpd.lkg.dec.com! 
sousa.tay.dec.com! bobseg.enet.dec.com! segrest@decwrl.dec.com 
Subject: Ethernet access to JNOS ??? 

To: packet-radio@ucsd.edu 


Can anyone tell me where the NOS Ethernet drivers are and what they are called? 


I would like to use a DEPCA Ethernet adapter manufactured by Digital Equipment 
Corporation with JNOS (WG7J). From what I have been able to gleen through a 
variety of sources there is a separate driver similar to a tsr that has to be 
loaded prior to starting JNOS. Then all you have to do is define the Ehternet 
port like any other on your system. 


Can anyone tell me where I can find out more about this? Does anyone know of 
someone that has tried this? 


Bob Segrest 
segrest@bobseg.enet.dec.com 


Date: 8 Jan 93 14:20:12 GMT 

From: news-mail-gateway@ucsd.edu 
Subject: FBB 5.14D Garbled Bulletins 
To: packet-radio@ucsd.edu 


Thanks for reading this posting. I am relatively new to this news group, so 
if I'm asking a question that has been recently dealt with, please use low 
intensity flames. 

I'm in the process of bringing up an F6FBB 5.14D BBS, and am also running 

the BPQ 4.06 node switch with it. This is on a '286 clone w/ 2 Mb memory. 
The problem I just observed last night is that messages/bulletins longer than 
approx 3.2K - 3.5K characters will be fine for the first page or so, then the 
remaining text in the bulletin is badly mangled. 


Has anyone with a similar set-up seen this same problem ?? 


If anyone has any hints/answers/guesses, please forward them to me 
at: anderson@sdd.comsat.com. 


Thanks, 
Gary (N3KCD) 


Date: 8 Jan 93 14:54:29 GMT 

From: idacrd!tang!n4hy@uunet.uu.net 
Subject: FEC 

To: packet-radio@ucsd.edu 


Date: 8 Jan 93 18:31:00 GMT 

From: news-mail-gateway@ucsd.edu 

Subject: Forwarded msg re: FBB and AA4RE issue. 
To: packet-radio@ucsd.edu 


Date sent: 8-JAN-1993 13:31:30 

> 

> 

>from Kd2aj @ kd2aj.d#neny.ny.usa.na 


>Recently I have found a number of message's at this BBS (REBBS Ver 2.12) 
>that have the wrong @ BBS in the FROM: line of the message. 

> 

>In researching this problem I found that if a particular BBS was in the 
>header list it always became the @ BBS on my FROM: line and to date has 
>always been an FBB BBS. 

> 

>Through further investagation by VE2BMQ Burt es myself we found a trend 
>in that the BBS prior to the above mentioned would have either the $:, 
>#:, identifiers in the wrong place and/or no #: message number at all. 
>After we had one BBS make a correction the problem with that BBS was fixed. 
>But due to the number of bbs"s with these errors it would be impossible 
>to talk to them all es I felt it was time for AA4RE Roy to shed some 
>light on this. 

> 

>Roy sent me a message as follows: 

> 

>"The current version 2.12 does a number "consistancy" checks on the header 
>and gives up scanning when they fail. The date/time must be reasonable; 
>the BBS callsign must be there; and either there is no message number 
>or a valid number must be there." 

> 

>This means that REBBS scans from top to bottom while other systems read 
>only the bottom line. When it encounters an error in the list it stops 
>and makes the last good line the last line on the header list and this 
>becomes the @ BBS on the REBBS FROM: line. 

> 

>While Roy states that "either there is no message number or a valid 
>message number must be there" I find that the valid message number must 
>be there. With KA2BQE Brian's idea of condensed R: lines (and I agree 
>with him) and WORLI implementation of condensed headers the message 
>number must exsist as it will enter a o (zero) if no message number is 
>found. REBBS scanning from top to bottom see this as an error es once 
>again stops scanning. 

> 

>I in no way mean to imply that only FBB users are in error on bad R: lines 
>but to date FBB line are the only bad lines I have seen. 


> 
>The bottom line is a long term es a short term fix. 

> 

>Long term: Roy tells me he is going to remove these consistancy checks. 
> This of corse will take time. 


> 


>Short term: To fix R: lines so that they meet at least the minimun 


> requirements. 

> 

> R:$3/$Kz @:$0$0 $:Q #:$M O:$P 

> 

> Note: 1. "O:" for the originatoris still valid but is no 
> longer required. 

> 2. The "z" is replaced by a space if BBS uses local 
> time. 

> 

>Thank you for reading this es wish all a Happy New Year 

> 

>73's Chuck KD2AJ.4INENY.NY.USA.NA 

> 

> 

Sosere End of message 1700 from KD2AJ @ KD2AJ. ----- 

>=> 

> 


Darrell G. Leavitt 
SUNY Empire State College (ESC) ESC VAX: DLEAVITT 


403 Sibley Hall SUNYNET: SESCVA: :DLEAVITT 

Plattsburgh, New York, USA,12901 INTERNET: LEAVITDG@SPLAVA.CC.PLATTSBURGH. EDU 
PHONE : (518) 564-2837 AX25/AMATEUR 

BitNet : LEAVITDG@SNYPLAVA PACKET: N2IXL @ KD2AI.d#NENY.NY.USA.NA 
Latitude: 44 41 58 N Longitude: 73 27 12 W 


Date: 8 Jan 93 18:26:33 GMT 

From: psinntp!isc-newsserver! cep4478@uunet.uu.net 
Subject: G3RUH DSP question (technical) 

To: packet-radio@ucsd.edu 


Hello - 


I am trying to learn about the G3RUH modem and understand how it 
ticks. I have recovered the unit sample response (impulse response - not 
the bit response) of the first set of samples in the transmit audio 
waveform generator, and they look like this: 


46 ,46,46,45,46,48,52,54,49,36,20,15,34,82,145, 200 
221,200,147,87,43,25,28,39,49,52,50,47,46,46,46,46 


Note that there are four samples per bit, therefore the sampling rate is 
38400 Hz. 


Here's my first question: if you take that unit response and run 
an FFT on it, you get a result in which the first lobe is at around 1200 Hz, 
which doesn't make any sense to me. Is this correct? 


Second, the hard one. I assume that the waveshape accounts for 
the phase response of the radio, and tries to precompensate it out. The 
fact that the impulse response (above) is not symetrical seems to confirm 
that some phase shifting is going on in the waveform generator. It isn't 
too hard to figure out the frequency response of the generator and compare 
it to the ideal response, and be able to derive the frequency response 
of the radio that this waveshape is intended for (simple use of the FFT 
vs. ideal frequency response). My second question is: how can I take the 
impulse response, figure out the intentional phase delay, and compare it 
against the ideal delay (none) to figure out the phase delay characteristics 
of the radio this waveshape was designed for? 


I am cross-posting this to comp.dsp, in addition to the packet 
group (rec.radio.amateur.packet) in case somebody there can help, so feel 
free to elminate the crosspost as appropriate. 


Chris 

Christopher E. Piggott, WZ2B cep4478@ultb.isc.rit.edu 
President wz2b.ampr [44.69.0.1] 
Rochester Institute of Technology wz2b @ WB2PST.#WNY.NY.USA.NA 
Amateur Radio Club K2GXT CEP4478@RITVAXA. BITNET 


Date: 8 Jan 93 21:10:46 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: Headers..... 

To: packet-radio@ucsd.edu 


In <O1LGTAOF38ASO9N4LMR@sSplava.cc.plattsburgh.edu>, 
LEAVITDG@splava.cc.PLattsburgh.EDU says: 


>While Roy states that "either there is no message number or a valid 
>message number must be there" I find that the valid message number must 
>be there. With KA2BQE Brian's idea of condensed R: lines (and I agree 
>with him) and WORLI implementation of condensed headers the message 
>number must exsist as it will enter a 0 (zero) if no message number is 
>found. REBBS scanning from top to bottom see this as an error es once 
>again stops scanning. 


WORLI generates a "short" header and substitutes a 0 if the message 


number is invalid or missing. Obviously the originating message 
number is NOT © but the new header says it is. I told WORLI this but 
he said that's the way the spec reads. I dunno what spec he was 
using. 


My code will see the number as invalid and will then assume that the 
rest of the message is text. If WORLI left the number off then 
everything would be fine. 


I also posted a message to this same forum telling people that this 
was happening a few weeks ago but received only one private message in 
response. 


Roy, AAARE 


For those who care, here is the original header spec with some 
comments from me where we have evolved on this: 


*xkxkk AA4RE Note x*x*xx 

Since the time of the spec, $: for the BID/MID was added as well 
as the need for hierarchical address info. The 0: for originator 
is still valid but no longer required. 

KKKKKKKKKKKKEKKKAK KEK 


R:870114/0819p S:870114/1206p AA4RE-1, Gilroy, CA -- 4983/NK6K 
NK6K/KE6BX/3830/Hollister, CA/870114/1019z 

/W6IXU//Arroyo Grande CA/Wednesday 14-Jan-87 at 1:48 AM 

R:870113/1606 @:NK6K Redondo Beach, CA #: 4104 O:NK6K F:145.36/.01 


Headers - a compromise proposal. 

(1/13/87) 

Note: These comments are necessarily terse, to make them easier to 
forward. This proposal is based on input from VE3GYQ, W3IWI, 

NK6K, WB6KAJ, and WB6YMH. 


Executive summary. 
A standard header format is proposed that permits 1) machine 


parsable headers, 2) human readability, 3) extendability 
4) standard non-standard information. 


Why we need a standard. 


There are at least two programs waiting to be written that 
require a machine readable header. One is a subroutine for BBSes 
that can find the originating BBS and send a service message 
back. The other is a FWD.TNC file generator that can determine 
paths and connectivity by examining passing headers. There are 
more. 


There is also a desire on the part of sysops to be able to rapidly 
scan a message by eye to look for bad routing, loops, dups, and 
delays. This task could be done programatically, but won't be 
for some time to come, and will never be performed by simpler 
programs on smaller machines. 


Why the current standards are not sufficient. 


Aside from the Sent and Received times, the R:S: format as 
current specified does not provide an easy way to programatically 
determine the following pieces of information: Originating User, 
message number. These items have been stated as necessary by a 
number o£ BBS sysops. 


The /this/that/ standard does not provide enough visual fidelity 
to permit the eyeball scan to take place. This is the reason 
most often cited for the lack of converts to this standard. The 
other shortfall is the lack of ability to add regional 
information in a standard way. Some areas or networks want 
additional information such as frequencies and grid, areacode, 
airport, or other positional identifiers. In a fixed field 
format where the item is identified by its location, null fields 
would abound when handling several optional special items, e.g. 
/call/call/city/state/rtime////freq///stime/. 


As of late, there are at least three different versions of the 
/that/that/ "standard", one with an area code field, one with a 
separate state field, and one without either. This of course 
invalidates an otherwise acceptable standard due to its 
dependence on field order. 


Attributes of an acceptable standard. 
Based on the stated wishes of developers, the following are the 


requirements of a well-formed header: Each field can be 
identified by a program. Some fields are required. 


Based on the stated wishes of some Sysops/Users, the requirements 
are: the header is eyeball-readable, the individual sysop can 
add information to suit his local needs. 


Stated more formally: 


Meet FCC third party requirements (whatever they are) 

Be compatible with existing software (able to be emitted) 
Be machine readable (read: easy to parse) 

Provide all necessary information 

Provide flexibility for optional information 

Provide some degree of user friendliness (read: looks nice) 


DnoBRWNPR 


Note: These comments are necessarily terse, to make them easier to 
forward. This proposal is based on input from VE3GYQ, W3IWI, 
NK6K, WB6KAJ, and WB6YMH. 


The proposal. 


These requirements are not mutually exclusive. Rather than use 
the fixed field/positional style of the /this/that/ standard to 
meet the machine readable requirement, a field identifier is 
proposed for each field. Note that the R:S: standard is already 
close to this. The only thing lost over the /this/that/ format 
is some efficiency, more characters are sent. Losses of 
efficiency are common when humans are involved. 


Proposed header format (for the machine readable camp): 


<header line> ::= <header field> [<header field>...] 

<header field> ::= <field identifier> <field contents> 

<field identifier> ::= <field type> ':' 

<field type> ::= any printable ASCII character except ':' 

<field contents> ::= a string of printable ASCII characters except ':' 
Rules: 

1. The ‘:' character may only be used as the termination 


character of a field type specifier 


2. The minimum items which should be included in ALL headers are: 
a) The callsign of the node relaying the message. 
b) The time the message was received. 


Items very (very) strongly recommended for all headers: 
a) the message number of the relaying node. 


b) the callsign of the station originating the message. 
c) the location of the node relaying the message. 


Optional information: 
a) Additional location information 
1. Grid squares 
2. Area codes 
3. longitude/latitude 
b) Frequency of operation of node 
c) time message was sent by node 
d) Network name 
e) group name 
£) Major maildrop (nearest major node) 


Field Identifiers: (Note new ‘field types may be defined as 
required) 


##: message number 


@: Node callsign followed by optional location 

A: node ALIAS 

F: frequency of operation. If gateway multiple frequencies are 
separated by "/" 

G: Grid square of node 

L: Long/Lat of node 

M: Major node callsign (nearest major relaying node, the APR 
proposal) 

N: Group, node, or network name 

0: callsign of originating station 

P: Telephone Area code of node 

R: Time message was received 

S: Time message was sent 


While many of the above fields may be deemed of value by 
different people the following suggested format is recommended 


R:861003/0739z @:W1BBS Packet city, KA #:1234 O:W1ABC 


Note if the timezone letter is not included it should be replaced 
with a space to preserve field alignment for visual fidelity. 


This header line provides the minimum information which is deemed 
necessary by large number of SYSOPs, based on current 
discussions. 


The proposed header format allows much flexibility for the 
individual sysop's without compromising the ability of software 
to extract the needed information. Following is an example of 
different headers which conform to this standard. Visual 
fidelity and machine readability is maintained. 


:861003/0701z @:KB3UD, East Bangor, Pa, G:FN20jv 
:861003/0641z @:K3RLI Wilkes-Barre, PA F:145.01/145.05 
:861003/0430 :N2AYY-1 Glens Falls, NY O:W1ABC 


:861002/1741z @:WB1IDSW O:W1ABC S:861002/2039z 
:861002/1523z @:W9ZRX #:8768 

:861001/1240 :WB6KAJ 

:861001/1836 :W6AXM-1 M:WB6KAJ O:W1ABC P:714 


AADAADA AAA A 


@ 
@ 
@ 
:861002/2040z @:WALFHB, Marlow NH #:5432 
@ 
@ 
@ 
@ 


Final Notes: The above differs from the current R:S: standard in 
that the S: field is missing from the first part. For visual 
fidelity to be maintained, all stations must agree to use the 
first two fields in that order. Those wishing to send the S: 
field may do so later in the header. Dropping the S: from the 
required fields is based on the premise that the S: field of a 
station can be inferred from the R: field of the next station. 


The RLI/MBL format for the minimum required format is: 
R:$3/$Kz @:$0 location #:$M 0:$P 


The "z" is replaced by a space if the BBS uses local time. 


Date: 8 Jan 93 19:58:59 GMT 

From: usc!howland.reston.ans.net!zaphod.mps.ohio-state.edu!darwin.sura.net!gatech! 
emory !ncratl!ncrhub2!ciss!law7!jra@network.UCSD.EDU 

Subject: Interfacing packet repeater and TNC 

To: packet-radio@ucsd.edu 


I'm working through the logic to tie a TNC directly into our full-duplex 
19.2kB packet repeater. 


It's pretty straightforward; DCD from the repeater receiver drives the 
TNC to prevent TNC data from mixing with repeated data, and vice versa 


to keep received data from grunging the TNC when it talks. 


But beyond that, has anyone come up with additional logic to improve 


performance? e.g., is it worth using latches to give one data source 
priority over the other? Are there race conditions to watch for? 


Any insight from those who've done this already would be appreciated... 


John R. Ackermann, Jr. Law Department, NCR Corporation, Dayton, Ohio 
(513) 445-2966 John. Ackermann@daytonoh.ncr.com 
Packet Radio: ag9v@n8acv.oh tcp/ip: ag9v@ag9v.ampr [44.70.12.232] 


Date: 8 Jan 1993 12:42:11 GMT 

From: mcsun!sunic!corax.udac.uu.se!neurofys.uu.se!per.ytterberg@uunet.uu.net 
Subject: NOS and POP 

To: packet-radio@ucsd.edu 


Which version of NOS (KA9Q) does have a POP server. The 93-01-04 version 


does not, or have I missed something? I downloaded it from ucsd.edu. There 
is a POPCLI.C in the source .ZIP but no "POPSERV.C". 


Per Ytterberg email: per. ytterberg@neurofys.uu.se 
Avd. £. Klin. Neurofys. Dep. of Clin. NeuroPhys. 
Akademiska Sjukhuset University Hospital 
751 85 Uppsala S-751 85 Uppsala 

Sweden 


Date: 8 Jan 93 20:50:31 GMT 

From: news-mail-gateway@ucsd.edu 
Subject: Packet Radio through Internet? 
To: packet-radio@ucsd.edu 


Hi all, 

is it possible to send mail from internet through packet radio and 
vice versa? If that's not the case, could someone relay messages to 
Germany? 

Thanks! 


Stefan Waas 


Scripps Institution of Oceanography 
University of California San Diego 


Physical Oceanography Research Division 


La Jolla, CA 92093-0230, U.S.A. 
Internet: swaas@ucsd 


Date: Thu, 7 Jan 1993 22:42:57 GMT 

From: pipex!slxsys!dircon!uab1017@uunet.uu.net 
Subject: SLIP on SUNs 

To: packet-radio@ucsd.edu 


Hello, 

I noticed some messages earlier about using SLIP interfaces 

on SUNs, well I would be interested if anyone could mail me 

a brief description of how to do it as I would like to be able 
to connect a sun network up to my P.C at home that currently 
runs WNOS3 running as a task under OS2v2 (which works very well). 


73 CharlesG4GUO 


mail to g4guo@dircon.co.uk or you could try g4guo@gb7eip.ampr.org 


Date: (null) 

From: (null) 

>The problem is that, although the bit speed of these systems is 8K - 9K6, the 
>perceived throughput is not that much greater than our boring old 1200/2400 
>baud 'straight' (non FEC) packet. 


This is a real 1200/2400 bps that is RELIABLE. It is not retry several 
dozen times and get a real throughput of 100 bps. 


BMc 


Date: Fri, 8 Jan 1993 16:24:07 GMT 

From: sdd.hp.com! zaphod.mps.ohio-state.edu!darwin.sura.net! gatech!kd4nc!ke4zv! 
gary@network.UCSD.EDU 

To: packet-radio@ucsd.edu 


References <1ihk85INNeh8@tamsun.tamu.edu>, <1iimg8INNsdm@network.ucsd.edu>, 
<1993Jan8 .083634.21991@qualcomm. com> 

Reply-To : gary@ke4zv.UUCP (Gary Coffman) 

Subject : Re: Who do repeater coordinators represent? 


In article <1993Jan8.083634.21991@qualcomm.com> karn@servo.qualcomm.com (Phil 
Karn) writes: 

>In article <1liimg8INNsdm@network.ucsd.edu> brian@ucsd.edu (Brian Kantor) writes: 
>>That's all well and good theory, Phil, but who is going to build it? 

> 

>Theory in ham radio, perhaps. Practice elsewhere. Anybody with the 

>time and the tenacity who wants to can build it. 


Building it is the easy part, convincing *xeveryonex else on the frequency 
to adopt it is the hard part. 


>>BTW, when are you going to put your antennas up? You've been living 
>>there at least half a year and you don't have ANY of them installed yet. 
> 

>When I get interested in ham radio again. 


That's depressing. 


Gary 


Gary Coffman KE4ZV 
Destructive Testing Systems 
534 Shannon Way 
Lawrenceville, GA 30244 


You make it, 
we break it. 
Guaranteed! 


gatech!wa4mei! ke4zv! gary 
uunet!rsiatl!ke4zv! gary 
emory !kd4nc! ke4zv! gary 
emory!ke4zv!gary@gatech.edu 


Date: 8 Jan 93 23:48:33 GMT 
From: ucla-se!malibu!nazareth@locus.ucla.edu 
To: packet-radio@ucsd.edu 


References <9301050143.AA00731@westport.trirex.com>, <CQE2nH.uqv@austin.ibm.com>, 
<1993Jan6 .091332.26965@qualcomm.com>' 
Subject : PAOGRI NOS QUESTION 


Hi, 


I recently downloaded a copy of PAOGRI NOS version 2.01 which the info command 
dates as 920725. I am trying to set it up such that I can have one computer 
physically connected to an ethernet network and also connected to a separate 
computer using a serial SLIP line. 


The idea is to be able to get the second computer, the one not connected to the 
ethernet, to be able to send/receive mail, and have ftp/telnet services. The 
ethernet network is part of the larger Internet. 


I have tried to set up the computers properly and have read the NOS operating 
manual, the Getting Started with TCP/IP by Ackermann, and the Beginners Guide... 
by Gary Ford. I have been able to connect the 2 pc's using the serial SLIP 
connection, but I have failed trying to communicate with the internet. 


I am including my AUTOEXEC.NOS file. Please examine it and let me know anything 
that I may do to accomplish this goal. 


Thanks in advance, 


Sean 
nazareth@janet.ucla.edu 


d## AUTOEXEC.NET 

d## This is a sample autoexec file for GRINOS version N1BEE 0.72. 

# It doesn't have all the fancy features one might hope for, but 
# the basics are there, with some hopefully useful comments. 

d## Any line beginning with a "#" character is treated as a comment. 
d## To uncomment a line, delete the # character 


d## NOS needs to know three things about you: your hostname, 

# your ham callsign, and your IP address. By convention, the 

d## hostname # is your callsign in lower case, followed by ".ampr.orgs". 
d## The callsign is generally used in upper case to distinguish it. 

d## The IP address comes from a local area coordinator. Note that 

d# there are a minimum of three places in this file where you need to 
d## insert your IP address -- here, in the ifconfig command, and at the 
d## end of each attach command. 

hostname test8.icsl.ucla.edu. 

ip address [128.97.90.158] 


# This should match your IP address 
ifconfig loopback ipaddress [128.97.90.158] 


i## PC setup 
isat on 
multitask on 


d# This makes short forms of the hostname work. 
domain suffix icsl.ucla.edu. 


d## NOS needs to know how to convert hostnames to IP addresses. 

# You can do this manually via the "DOMAIN.TXT" file, or you can 
d## use a nameserver if one is available. To enable the 

d## nameserver, uncomment this line and plug in its correct 

d## address. 

domain addserver [128.97.92.2] 


d## Some additional commands for the domain service. Don't turn 

d## translate on unless you have a small domain file and/or a fast machine. 
domain verbose off 

domain cache size 40 

domain translate off 


d## To use POP, uncomment these lines. Fill in "pop mailhost" with 

d## the IP address of the station serving as your POP server. Fill in the 
i "popi# mailbox" name with your hostname, i.e., your call. The "pop 

# userdata" line needs to have your hostname, followed by a password 

dF (as negotiated with your mail server). "pop timer" sets 

d# how often, in seconds, to query for mail. 

dtpop mailhost [44.xx.xx.xx] 

d##tpop mailbox hostname 

##pop userdata hostname password 

##tpop timer 1800 


d## Attach commands are complex; these are samples for COM 1 
d# and 2. See Appendix C for details. Uncomment the 

4 appropriate line(s) for your hardware. 

d## COM1 -- 256 byte MTU, 4800 baud serial link as ax0 
attach asy Ox3f8 4 slip sl0 4096 1500 9600 

attach packet 0x60 ecO 5 1500 

#attach asy Ox3f8 4 slip slO 2048 256 4800 

dF COM2 -- 256 byte MTU, 4800 baud serial link as ax1 
#attach asy Ox2f8 3 ax25 ax1 2048 256 4800 


d## This is the basic route, sending everything out ax0 
route add default ecO 
route add 128.87.90.159 sl0 


d## These are tcp parameters you shouldn't need to mess with. 
ip ttl 16 

ip rtimer 240 

tcp irtt 3000 


d## On a shared channel, you may want to change timertype to 

d## exponential; that's more courteous, but will slow your 

d## retries down significantly. mss and window should ordinarily be 
d## the same value, equal to the largest mtu set in the attach 

dF command(s) above minus 40. With the common mtu for 1200 baud 

d## channels of 256, that means both mss and window should be 216. 
tcp timertype linear 

# tcp bblimit 16 

tcp mss 1460 

tcp window 2920 


d## These set up AX.25 parameters 
ax25 digipeat off 

ax25 maxframe 1 

ax25 paclen 256 

ax25 retry 20 

ax25 window 4096 

ax25 blimit 15 

ax25 version 2 


## as with tcp timertype, you may want to set this to 
d## exponential on a shared channel. 
ax25 timertype linear 


d## These are netrom setup commands. Don't turn them on 

d## unless you need them, and you know what you're doing. You 
d## can really screw up the network by putting out netrom 

## broadcasts that don't fit with the configuration of the 
# "real" netrom nodes that can hear you. 

#attach netrom 

d#netrom interface axO MYALIAS 192 

d##netrom obsotimer 1800 

d#netrom nodetimer 10800 

d##netrom verbose yes 

d##netrom bcnodes axO 

#netrom ttl 8 


d# These start the servers. 
start smtp 

start ftp 

start echo 

start discard 

start telnet 

start finger 

start ax25 


d## Uncomment this line to enable logging. 
d##log \spool\net.log 


# Default file type for ftp transfers. Type image is for binary files; 
i## type 

## ascii is for text; it's safest to set the default to image. 

d## ftype image 


## This makes telnet sessions to Unix systems work 
# line-by-line, rather than character-by-character. 
echo refuse 


iF 


Tell smtp how often to scan for outgoing mail 


##smtp timer 600 
##smtp batch on 


dF 
dF 
dF 
iF 
dF 
iF 
dF 
iF 


dF 
iF 


GRINOS can send a string of commands to the TNC on startup. 

You could use this to force the TNC into KISS mode. Note that 
you need to specify which interface to use. This must be done 
<after>defining the interface, and <before>any data is sent to 
the TNC (for example, by the smtp and pop kick commands below). 
These commands will do that for a TNC2: 

comm ax0 "kiss on" 

comm ax0 "reset" 


kick the smtp and POP servers at startup. Only uncomment the 
"pop kick" line if you've defined a POP server above. 


d##smtp kick 
d#Fpop kick 


dF 
dF 
iF 
iF 
dF 
dF 
iF 
dF 
dF 
dF 
iF 


iF 


GRINOS (but not other versions) can define the function 
keys with macros to make things a bit easier. Here are a 
couple of examples. Note that each command must end with 
a "\n" to signify a carriage return. The numbers 
represent the keys; 59 - 68 for F1- F10 (though F10 can't 
be redefined; it's always the escape key), 84 - 93 for 
shiftFi - shift F10, 94 - 103 for ctrlF1 - ctrlF10, 104 - 
113 for altF1 - altF10. 

fkey 59 "tcp status\n" 

fkey 60 "mem status\n" 

fkey 61 "status\n" 


THE END 
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